Subject: Capabilities SIGlet Kickoff

From: [email-masked]
Date: Tue, 13 Jul 93 14:51:32 PDT

Fellow Capabilities SIGlet Members:

    I apologize for the delayed start in the Capabilities Exchange SIGlet.
    I have been deeply involved in the Connect/Disconnect SIGlet but I will
    attempt to take a more balanced approach in the future.

    The first thing I'd like to do is query the members to see what they
    believe to be the goals of this SIGlet.  I will start off by presenting
    my view.  I welcome any and all responses.

    Statement of Purpose
    --------------------
	Since it might not be possible for every implementation of Data
	Link Switching to provide all of the capabilities of the eventual
	DLSw specification, it is highly desirable to:
	  (1) break the set of DLSw features up into a base set and 'n'
	      option sets (where 'n' will be determined as the DLSw spec
	      evolves),
	  (2) provide a mechanism so that partner DLSw implementations can
	      exchange information about which capabilities they support.

	Number (1) means that we have to not only closely examine the current
	DLSw specification to see what could be considered optional in any
	given implementation but also to track all other SIGlet activities.

	Number (2) is "simply" working out the details of the format and
	protocols between two DLSw's.

    Identification of Base Set and Option Sets
    ------------------------------------------
	There are 2 aspects of identifying the base set of properties of
	DLSw:
	  (1) what parts of today's DLSw RFC should be considered optional
	      (if any), and
	  (2) what parts of the ongoing SIGlet work results in optional
	      features.

	Number (2) requires a little forethought on the part of the design
	of new features and I will alert aiw-sig-dlsw-coordinators to this 
	effect.  The Capabilities Exchange SIGlet needs to closely track
	the effort of other SIGlets so I will be requesting volunteers
	from this SIGlet to monitor each of the other activities.

    Capabilities Exchange Protocol
    ------------------------------
	It seems to me that two DLSw implementations need to exchange
	capability information at the time of initial contact.  This
	means the switches need to know about each other before the
	CANUREACH/ICANREACH exchange.

	In lieu of a DLSw discovery protocol, a particular DLSw would
	have to be configured with the IP address of all participating
	DLSw's (like today's 6611 is).  Also, each DLSw would have to
	associate a certain set of capabilities with each possible DLSw
	partner (keyed by IP address) so that the local DLSw would know
	what properties were supported remotely.

	For the sake of argument, let's say the capabilities exchange
	is UDP-based and operates somewhat like OSPF's HELLO packets.
	For brevity, let's call the capabilities exchange packet CAP_EXCH.
	When a target DLSw receives a CAP_EXCH from a previously unknown
	origin DLSw (as keyed by the IP address), the target DLSw issues
	a CAP_EXCH of its own back to the origin.

	The end result will be a mesh of DLSw routers that understand
	the capabilities of every other DLSw in the mesh.  This does
	raise questions of scalability so I'm really open to suggestions
	here.

	If a downrev router that doesn't support capabilities exchange
	gets the CAP_EXCH (e.g. today's 6611), it merely drops the datagram
	and no harm is done.  The end result of not replying is that a 
	downrev router is not in the DLSw mesh.  It can still operate
	with other downrev routers and other routers for which CAP_EXCH
	is optional (strongly discouraged).

    Capabilities Exchange Formats
    ------------------------------
	The format of CAP_EXCH can either be simple or complex.  On the simple
	end, the format could be a series of bit or byte flags with one bit
	or byte position for each feature.  On the complex end, the format
	could be a formal structured data stream like APPC's Generalized
	Data Stream with LT and/or KL structured subfields, like that
	used by SNA/DS, DIA, and other architectures that sit atop APPC.
	There are plenty of solutions between these two extremes.

	Some of the things that should be considered when making such a 
	decision are:  (this is a straw-man, no flames please)
	    - extensibility: how do you easily add more fields in subsequent
	      revisions of DLSw?
	    - data representation: are there boolean vs. multi-valued 
	      variables?
	    - code complexity: most routers and converters don't have 
	      extensive data stream parsing logic today (like GDS Variable
	      and structured subfield handling),
	    - id assignment: it would be politically incorrect to use
	      reserved GDS Ids (!).

	There are a few additional items that I believe should be in the
	capabilities exchange that are not related to base set and option
	set:
	  (1) vendor id: a unique value that identifies the manufacturer
	      of the DLSw (presumably assigned by the AIW or IETF (?) ),
	  (2) vendor version number: the vendor's own identifier for the
	      version of software running in the DLSw,
	  (3) DLSw version number: an identifier of which rev of the DLSw
	      spec is implemented (incremented as DLSw specifications
	      go through different RFC numbers).

    As I mentioned at the start, I welcome any and all responses.

Regards,
-----------
Wayne Clark
cisco Systems, Inc.
[email-masked]
415/688-4627

---

From: "Bernard Brady" <[email-masked]>
Date: Wed, 14 Jul 93 09:02:14 EDT

>    Capabilities Exchange Protocol

Wayne,

Why use UDP to exchange capabilities when there is already at least one
TCP/IP connection between the DLSws.  If the reason is so exisiting
6611s and newer routers can coexist then what does the current version
of the 6611 do when it receives an unknown messages type?   It seems
that by using UDP it will complicate DLS if it moves to other transport
connections such as OSI TP4.

Bernie

---

From: [email-masked]
Date: Wed, 14 Jul 93 07:43:54 PDT

>connections such as OSI TP4.

Bernie -

    I was thinking that characteristics that were discovered in the
    capabilities exchange might affect the parameters of the TCP open
    call on the router.  For instance, if both DLSw support the frambis
    mode of operation and that the frambis mode has to be specified
    when the TCP session is opened, then the capabilities exchange has
    to happen out of band.

    I don't really have any such characteristic identified yet, but if
    there was, then the capabilities exchange would have to occur
    before any TCP sessions were opened.  Thus UDP.

Wayne